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REMARKS 

It is noted from the latest Office Action(s) that the applications cited in the 
information disclosure statement mailed 12/03/03 were not necessarily considered. 
Submitted herewith is yet another copy of such information disclosure statement, so that such 
references may be considered, and such consideration may be documented in the record. See 
MPEP609D below: 

"Applicants may wish to list U.S. patent application numbers on other 
than a form PTO-1449 or PTO/SB/08A and 08B format to avoid the 
application number© of pending applications being published on the 
patent. If a citation is not printed on tbe patent but has been 
considered by the examiner in accordance with this section, the 
patented file will reflect that fact as noted in subsection 1IX.C(2) 
above." 

The Examiner has maintained the current rejection. As set forth below, such rejection 
is sail deficient. However, despite such deficiencies and in the spirit of expediting the 
prosecution of the present application, applicant has incorporated the subject matter of Claim 
8 et aL along with additional claim language into each of the independent claims, 

The Examiner has rejected Claims 1, 4, 6, 9, 12, 14, 18 and 21 under 35 U.S.C. 103(a) 
as being unpatentable over Fanning et aL (U.S. 6,742,023), in view of Sull (U.S. 
2002/0069218), in further view of Cooper (U.S. 2001/0051996), in further view of Ritter 
(U.S. 2004/0199474), The Examiner has rejected Claim 8 under 35 U.S.C, 103(a) as being 
unpatentable over Fanning-Sull-Cooper-Ritter in view of Morris (U.S. Patent No. 6,496\851). 
Applicant respectfully disagrees with this rejection, especially in view of the amendments 
made hereinabove to each of the independent claims. 

The Examiner has responded to applicant's arguments and has stated that they are not 
persuasive. First, with respect to the independent claims, the Examiner has stated that a URL 
can be any type of marker that forms a representation of a resource. Applicant respectfully 
disagrees with such an assertion. The ordinary meaning of URL (uniform resource locator) is 
the address of a resource on the internet. Thus, the URL is the web address where the 
resource can be located and not simply any type of marker, a$ the Examiner suggests. In 
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view of this, it is clear that Fanning does not teach tc receiving a response to the request 
containing a local alias URL" since Fanning merely teaches a search response containing file 
descriptions matching a search recpiest (Col. 3, lines 17-18) where the file description can 
contain a file name (Col. 10, lines 49-65). Clearly, merely disclosing a file name, as in 
Fanning, does not meet applicant's specific local alias URL . 

In addition, the Examiner has stated that Fanning teaches URL's that are returned as 
results of a file search, which correspond to various back-end servers. Again, applicant 
respectfully disagrees. Simply nowhere in Fanning is there any disclosure of a cc backend 
server" in the context claimed by applicant, namely broadcasting a request "for a task with 
respect to a remote non-local backend server " In feet, Fanning teaches the "distribution of 
data files between users in a networked community of users... where each user [has] a 
distribution application., .[and] the distribution application additionally includes a data file 
transfer server that makes available all data files" (see Abstract). Thus, in Fanning, users 
only download files from the data file transfer servers of other users* and not from backend 
servers, as claimed by applicant. 

In the latest Advisory Action dated 7/26/05, the Examiner has responded to 
applicant's arguments by stating that other peers may be in the form of servers because they 
achieve identical functions. In making such an assertion, it seems the Examiner has failed to 
consider the full weight of applicant's claim language. Specifically, applicant does not 
merely claim servers, as argued by the Examiner, but instead claims a backend server . 
Applicant respectfully asserts that peers would not be in the form of a backend server. 

Second, still with respect to die independent claims and regarding the concept 
presented in placing objects in a black list, the Examiner has concluded that it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to place 
offending servers into a black list. Applicant respectfully disagrees with such an assertion. 
The cited prior art specifically relates to a transaction between a client and a terminal, where 
the terminal is a fixed point-of-transaction (POT) apparatus, such as an ATM (see Ritter 
[0002-0003]). Further, Ritter teaches that the POT apparatus contains a blacklist of clients to 
be barred from using the apparatus ([0061] and [0074]). 
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Thus, it would not have been obvious to combine Ritter's POT invention with 
applicant's peer-to-peer network since they are of completely different fields of endeavor. 
Moreover, Ritter completely feils to teach placing a server node on a black list if the receipt 
packet is not from the remote non-local backend server to which the request was broadcasted. 
Ritter doesn't even teach the means by which a user is placed cm the blacklist, but simply 
discloses the use of a blacklist. In view of this, it is clear that it would set have been obvious 
to take Ritter's (or any of the other cited references', for that matter) mere mention of a 
"blacklist" and modify it to meet applicant's specific claim language. 

In the latest Advisory Action dated 7/26/05, the Examiner has responded to 
applicant's arguments by stating the concept of blacklisting underperforming servers is well- 
known in the art. In response, applicant again points out the remarks above that clearly show 
the manner in which the prior art is distinguished, Applicant thus formally requests a specific 
showing of the subject matter in ALL of the claims in any future action. Note excerpt from 
MPEP below. 

*If the applicant traverses suck an [Official Notice] assertion the 
examiner should cite a reference in support of his or her position. " 
See MPEP 2144.03. 

Third, the Examiner has stated that in light of Fanning's teaching of filtering servers 
by parameters of bandwidth, dependability, etc,, it would have been obvious to one of 
ordinary skill in the art at the time of the invention to place the filtered servers into a group, 
such as a blacklist in view of Ritter's teachings. Applicant agrees that Fanning teaches 
filtering servers by parameters of bandwidth, but applicant asserts that such servers are 
filtered before the request is broadcasted by the user entering search criteria into the search 
module that limits bandwidth to a network (see Col- 10, lines 55-65). 

Applicant, on the other hand, claims "awaiting a maximum upload receipt time period 
for receiving the receipt packet" ($ee Claim 3 et al.) and "placing the server node in the black 
list of the requesting peer if a receipt packet fails to arrive within said maximum upload 
receipt time period" (see Claim 4 et al.). In addition, applicant claims "wherein the 
maximum upload receipt time period is set based on a frequency of which an uploading 
service at the responding server node performs an upload, a size of a file being uploaded, and 
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a transmission speed" (see Claim 17). Thus, applicant's claim language clearly differs from 
Fanning' s disclosure in that applicant only places the server node on the blacklist if it does 
not send a receipt packet before the specified time period, and not simply based on a 
predetermined bandwidth as taught by Fanning. 

Lastly, the Examiner has stated that Morris does teach 'forwarding the task to the 
local alias URL from performance of the task by the responding server node" (see 
independent claims) including "forwarding a file to be uploaded to the remote non-local 
backend server" (see Claim 8 et al.). The Examiner has stated that, in Morris, one of the 
users requests the other user to upload a file and that the representation of the receiving user 
is also in URL form. Applicant respectfully asserts that Morris simply teaches users sending 
a receiving, and not forwarding a file to be uploaded to the remote non-local backend server. 
as claimed by applicant, Specifically, applicant claims that a peer broadcasts the request (see 
independent claims) and then the file is forwarded to be uploaded to a remote non-local 
backend server ($ee Claim 8 et al.) a and not simply file sharing between two users as in 
Morris. 

Nevertheless, despite such paramount distinctions and in the spirit of expediting the 
prosecution of the present application, applicant has amended each of the independent claims 
as follows, including in part the subject matter of dependent Claim 8 et al. Applicant 
respectfully asserts that the prior art does not meet dependent Claim 8 for substantially the 
reasons stated above. In addition, applicant respectfully asserts that the prior art also fails to 
meet the new claim language currently included in each of the independent claims, as 
emphasized below. 

"broadcasting a request over the network by a requesting peer for a 
task with respect to a remote non-local backend server; 

receiving a response to the request containing a local alias URL, the 
local alias URL pointing t o a local upload directory for a vendor HTTP 
service server residing-a-desfeaMoft on a responding server nod e, where the 
vendor HTTP service server uploads files from the local unload directory 
to the remote non-local backend server : 

forwarding the task to the local alias URL for performance of the task 
by the responding server node; 
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verifying a digital signature of any receipt packet received from the 
responding server node to ensure that the receipt packet is from the remote 
non-local backend server; and 

awaiting a maximum upload receipt time period for receiving the 
receipt packet 

wherein the maximum upload receipt time period is set based on a 
frequency of which an uploading service at the responding server node 
performs an upload, a size of a file being uploaded, and a transmission speed; 

wherein the server node is placed in a black list of the requesting peer 
if said verifying is unsuccessful; 

wherein, after said receiving, a message is broadcasted indicating that 
the requesting peer has located the responding server nodei 

wherein the task is an uploading task and wherein said forwarding the 
task to the local alias URL includes forwarding a file to be uploaded to th^ 
remote non-local backend server, and uniquely identifying the forwarded 
file." 

In addition, applicant respectfully asserts that the prior art does not meet applicant's 
remaining claim language for substantially the same reasons as argued with respect to the 
prior office action* 

For example, die Examiner relies on the following excerpts from Fanning to make a 
prior art showing of applicant's claimed "receiving a response to the request containing a 
local alias URL, the local alias URL pointing to a destination on a responding server node" 
(see this or similar, but not identical, language in all of the independent claims). 

^distribution application, wherein the search response comprises 
file descriptions matching the search request." (Column 3 lines 17- 
18) 

tt ...an automatic selection module, wherein a data file description is 
automatically selected and the associated data file iB downloaded, 
the automatic selection module choosing- a data file description..,* 

(Column 3 lines 50-52) 

11 FIG. S shows the preferred embodiment, where the system of the 
present invention utilizes a search module 806 for searching the file 
index, in which a search request submitted by the distribution 
application 800 is processed and a search response, containing file 
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descriptions matching the search request, is returned to that 
distribution application 800, When a user wishes to locate a 
particular data file, the search module 800 constructs a search 
request to the file index 810 based on the search criteria specified 
by the user through the distribution application 800, The search 
criteria can contain a complete filename or a subsection of the 
filename, limitations on any of the fields of ancillary data, the 
file size, or limitations on the file transfer server including 
bandwidth to network or percentage of successful downloads. The index 
server 808 executes the search request, prunes the file descriptions 
as appropriate, and displays the search response to the user. 1 ' 
(Column 10 lines 49-65) 



Such excerpts, however, merely suggest search responses including file descriptions- 
There is not even a suggestion, however, of any sort of responses including a URL, let alone 
a local alias URL that points to a destination on a responding server node . 



The Examiner purports that 'Hhe returned results and data file descriptions are in URL 
form." Applicant respectfully disagrees. Such file descriptions merely comprise: a title of 
the data file, the size of the data file, the type of data file, any text associated with the data 
file, the creator of the data file, the quality rating of the data file, and the distribution 
application where the data file resides. None of such entities involve a URL f as specifically 
claimed. Only applicant teaches and claims such a local alias URL pointing to a destination 
on a responding server node, in the context of the claimed invention. 



Still yet, the Examiner relies on the following excerpt to make a prior art showing of 
applicant's claimed "forwarding the task to the local alias URL for performance of the task 
by the responding server node" (see this or similar, but not identical, language in all of the 
independent claims). 



"Using the displayed sorted search response, the user can select one 
of the data file descriptions, thus initiating a download of the data 
file using the file transfer client 114. The user interface 118 shows 
the status of each download. Any download can be canceled prior to 
completion. Interrupted downloads are displayed as well. 

In the preferred operation, the system of the present invention 
distributes data files as shown in FIG. 4. After a distribution 
application is connected to the system, the process begins 400. The 
first step 4 02 is that a first distribution application connects to a 
second distribution application. Following, the next step 4 04 is that 
the first distribution application requests a data file from the 
second distribution application. In step 406, the second distribution 
application transmits the data file to the first distribution 
application. Next, in step 40$, the first distribution application 
stores the data file into the data file repository. Then, as shown in 
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step 410, the data file is placed in the first distribution data file 
repository and is automatically made available to other distribution, 
application in the community." (column 12 lines 6-29) 

By virtue of the fact that Fanning does not even suggest a response including a URL, 
as claimed, there can not be a suggestion of any sort of forwarding of the task to the local 
alias URL for performance of the task by the responding server node, 

In the latest Advisory Action dated 7/26/05, the Examiner has stated that forwarding 
media files to users is well-known in the art. However, applicant claims "forwarding the tesk 
to the local alias URL for performance of the task by the responding server node," (emphasis 
added) and not merely forwarding media files to users, as suggested by the Examiner. 

Even still yet^ the Examiner relies on the following excerpt from Fanning to make a 
prior art showing of applicant's claimed "wherein, after said receiving, a message is 
broadcasted indicating that the requesting peer has located the responding server node" (see 
this or similar, but not identical, language in all of the independent claims). 

"Using the displayed sorted search response, the user can select one 
of the data file descriptions, thus initiating a download of the 
data file using the file transfer client 114. The user interface 11B 
shows the statue of each download. Any download can be canceled 
prior to completion, interrupted downloads are displayed as well.- 
(column 12 lines 6-13) 

The Examiner continues by arguing that "where the downloading from the server 
would necessitate the reception of a message that the requestor has located the responding 
server." Applicant respectfully disagrees with this assertion, as downloading from the server 
would not necessitate the broadcasting of a message indicating that the requesting peer has 
located the responding server node, especially after receiving a response to its request as 
claimed. 

In the latest Advisory Action dated 7/26/05 3 the Examiner has stated that broadcasting 
a message constitutes a design choice rather than a patentable distinction. Applicant 
respectfully disagrees. Applicant claims that "a message is broadcasted indicating that the 
requesting peer has located the responding server node " which informs other peers that a 
responding server node has been located in association with the broadcasted request. Thus, 
clearly such language is not merely a design choice, as suggested by the Examiner, since 
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broadcasting in the manner claimed by applicant has at least one purpose, including 
informing other peers. 

It appears that the Examiner has relied on an inherency argument regarding the above 
emphasized claim limitations, hi view of the arguments made hereinabove, any such 
inherency argument has been adequately rebutted, and a notice of allowance or a specific 
prior art showing of such claim features, in combination with the remaining claim elements, 
is respectfully requested. (See MPEP 21 12) 

To establish aprtma facie case of obviousness, three basic criteria must be met. First, 
there must be some suggestion or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must teach or suggest all the 
claim limitations. The teaching or suggestion to make the claimed combination and the 
reasonable expectation of success must both be found in the prior art and not based on 
applicant's disclosure. In re Vaeck,947 F.2d 488, 20 USPQ2d 1438 (Fed.Cir.1991). 

Applicant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art references, when combined, fail to teach or 
suggest aU of the claim limitations, as noted above. Again, a notice of allowance or a specific 
prior art showing of each of the foregoing claimed features, in combination with the 
remaining claimed features, is respectfully requested. 

Still yet, applicant brings to the Examiner's attention the subject matter of new Claims 
22-27 below, which are added for full consideration: 

cc wherein the packet includes the following format: <service type = "X rt 
version = "X" ID = "X" method = "X" href ~ http://X acceptprotoco = <*X?/>> 9 (see 
Claim 22 et al.); and 

''wherein the files each include an XML file" (see Claim 23 et al.). 
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In conclusion, all of the independent claims are deemed allowable. By virtue of their 
dependence on such independent claims, all of the remaining claims are further deemed 
allowable. 

Reconsideration is respectfully requested. 

In the event a telephone conversation would expedite the prosecution of this 
application, the Examiner may reach the undersigned at (408) 505-5 100. For payment of the 
fees due in connection with the filing of this paper, the Commissioner is authorized to charge 
such fees to Deposit Account No. 50-1351 (Order No. NAI1P277_01.0I6.01). 

Respectfully submitted, 



P.O. Box 721 120 

San Jose, CA 95172-1120 

Telephone: (408)505-5100 
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